Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/833

Internet Message Format | 1994-08-27 | 7.2 KB

From: [e-mail] (Michel Forget)
Subject: Re: Gem List (corrected) (fwd)
Date:     Sun, 17 Jul 1994 06:55:54 -0600
Precedence: bulk

Hello Ken,

Please post from your own account, or sign-up the account you are posting
from.  Would it really be that hard?

>Sounds like some of us enjoy re-inventing the wheel.

Some of us do, if the wheel was brain-dead to begin with...  :)

>> Warwick built GEM++ from scratch, so he did all the hard work.  Now if _I_
>> use GEM++ for a dialog-in-a-window or something, it takes about 5 lines of
>> code.
>
>Ooh, so I guess it's the *best* library out there from the way you speak?

GEM++ is very nice; I cannot speak for it from a programming aspect, but
using it is very easy for the user.  From the comments of the various
programmers, programming with GEM++ is simplicity itself, which is not
true of most dialog libraries.  For example, as good as EGEM is, it is
not easy to write a program using it unless you do so from scratch.  It
expects your program to conform to a RIGID set of "features" (like
absolute true non-modality).

>There. That was really difficult wasn't it? Now with the new window installed,
>it WinLIB PRO handles the dialog, lets you move it, BACKGROUND click buttons
>with the LEFT mouse button (and not some LAME left-right button simultaneous
>click, I might add) and close it. WinLIB PRO handles everything for you when
>you return a FALSE in the window dispatcher code.

Is this really important?  Three lines of code, five lines of code, who
really cares?

>Gheez, like that's hard to code or something? So how do you set an
>'active slider' in Gem++ without using special code (since you said you
>don't write any special support code for it) and without doing anything
>special to the RSC with a RSC editor (ooh mommy, changing the extended
>object type is soooo hard!)

Does your sarcasm ever end?  I'm probably not alone in finding it
annoying, and certainly misplaced.

>>From the consistent evasions of my questions, it's obvious you know nothing
>about extended object types. (And yes, I fully expect you will dodge this
>statement with yet more doublespeak).

Exactly what is it you want us to know about them (other than the fact that
you have supperior knowledge of them).  I'll be the guinee pig, then.
I know nothing of any importance about extended object types; I do not
use them, and have no particular use for them.  Now what should I know?

>> I guess you've never compared the GUI code for an *application* using GEM++
>> to that built with a "normal" library...
>
>That's true. Because there *ARE* no applications written using Gem++.

GEM NetHack, GEM GNU Chess.  If C++ ever becomes more popular on the
Atari, I'm sure more people will use GEM++.

>> 1) They're afraid of GNU C/C++, since it's not a commercial product.
>
>Wrong. I have no problems with using PD compilers. The reason I stay away
>from Gnu C/C++ is that I don't have the resources to waste (i.e. tons of RAM,
>and tons of diskspace). And the fact that Gnu C++ spits out binaries roughly
>5 to 20 times bigger than the *same code* in Pure C.

This figure is... <censored>.  Try, on average, less than 50%-60% larger.
There are other public domain compilers, like SozobonX, that produce
good object code.

>> 2) There's no commercial C++ implementation for the Atari.
>
>So?  The Atari's dead, anyway.

Well, there's a cheery thought, huh?  :)  So why -are- you here, exactly?

>--Ken Hollis (Bitgate Softwate)

>Background tasks are *meant* to be less responsive than the foreground
>task. Otherwise there would be no distinction between the two. :-)

What on earth are you talking about?  Wasted CPU time is waster CPU
time.  It has nothing to do with how responsive the background
application is.  Wasted time affects performance, plain and simple.

>Better yet, break out a debugger and check things out for yourself. You DO
>know how to use an assembler-level debugger do you not?

Maybe he does, but I do not.  That would require assembly language
programming skills, which not everyone has (or needs).

>I've used MTOS enough to be disgusted with it. It's a piece of crap. Slow,
>and inefficient.

Slow, inefficient, STANDARD.  People use it, and like it.  They may all
have fast machines, but they are still using it.

>Our multitasking design *requires* that we have a 0ms timer event, since
>we allow multiple threads of execution within one GEM program, even without
>MultiTOS. You are free to use slower timer events, but your subthread
>performance will suffer.

This sounds more complex that a dialog-library needs to be.  You mention
that nobody uses GEM++, but will anyone use your library?  Not many people
need threading, or the replaced AES functions that your library drags
along with it.

>So, you're saying we NEED to watch for mouse rectangle events when our
>application is not topped? That makes very little sense at all.

Why does this not make sense to you?  This discussion started with
an argument over changing the mouse shape when it passes over a
specific object type.  Why should your program stop doing this
just because it is not the top application?  If the mouse passes over
one of the object types in your dialog (even untopped) it should
change shape.  If you do something, do it right and do it completely.

>Wrong. You do not "have" to do this. The slider in WinLIB PRO is defined by
>its relation in the object tree to its parent object, and its extended object
>type. There is *NO* reason whatsoever that you have to "attach" a child
>object to its parent with some code to make it an active slider. In a good
>library, this should be an inherent property from the structure of the RSC
>file.

Umm, this may sound like a stupid question, but what about if the contents
of your active slider CHANGES.  If you start with three items in your
resource file, but suddenly need to put fifty in the active scroller,
will that not cause problems?  What if you start with fifty and
suddenly decide you only need three?  Do you just let the memory being
used by the list go to waste?  I much prefer having to link a list of
text items to the slider, since that way I can grow/shrink the list
whenever I feel like it.

>The point is that whereas in WinLIB PRO, these changes can be made with a
>RSC editor, whereas in Gem++ it requires code changes and recompilation.

If you change the resource structure, you will have to recompile your
program no matter what, so this is not really a consideration unless
the changes you are making are trivial (in which case you would not
have to recompile no matter which library you use).

>Why bother designing a GnuC++ based library when only a tiny fraction of the
>programmers out there can use it? That seems to me like cutting your own
>throat.

Why bother designing WinLIB PRO and then insulting just about every
programmer who would consider using it?  I cannot speak for Warwick,
but I assume he wrote it because he wanted to use it, or he wanted
to improve C++ for the Atari.

[You know, your messages in this digest were all posted twice...]


--
Michel Forget           \\   [e-mail]    //
Electric Storm Software  \\  [e-mail]               //
PGP Public Key Finger. = 1F C0 D3 FE 40 51 7F 47 F3 4A C6 A0 6E 02 71 85